As the twentieth century draws to a close, the computer industry finds itself facing a problem, which if unsolved by the year 2000, will cause serious repercussions beyond the computer industry. The collapse of global markets and economic depression have been cited as just two examples of the potentially catastrophic results of failing to cure the Y2K problem. Regardless of the accuracy of such doomsday predictions, there is consensus among experts that, at the very least, a great deal of money and time will be devoted to avoiding and/or correcting the Y2K problem and its effects.
Ironically, the people most responsible for the problem are those most likely to economically benefit from the need to avoid and/or correct it. The Y2K problem originated in the initial short-cited decision to assign only two digits for the year field within the date field (e.g., YYMMDD, wherein YY is the year of the century, MM is the month and DD is the day) in computer programs, because computer memory was very expensive and the year 2000 seemed very distant. Programmers continued to adhere to this initial convention until relatively recently, despite the advances in memory and the approach of the year 2000.
In the date format typically used over the last thirty years or so, the year 2000, 2001, et seq. is represented by the two digit codes of 00, 01, et seq. Accordingly, computer systems employing the obsolete date format without modification will be unable to distinguish between the year 2000 and the year 1900, for example, as the latter is also represented by the two digit code 00. Thus, if the computer system was, for example, to compare dates such as 1994 and 2000 to determine which was greater, an erroneous result would occur as the system would interpret the two digit representation of year 2000 (i.e., 00) as being less than the two digit representation of year 1994 (i.e., 94).
A number of purported solutions to the Y2K problem have been proposed.
One solution to this problem would be to convert all dates within the application system of the computer to use date fields with four digit representations for the year. This, however, is a relatively expensive solution for a variety of reasons. First, this solution requires the creation and testing of programs to convert all date fields in all application files. Second, this solution requires the creation and testing of all modifications to all date field processing routines currently used by the application system. Finally, this solution requires conversion of all files to the new formats together with implementation of all of the modified application processing routines. Other problems with this solution, apart from the cost, include the significant amounts of system downtime during the file conversions and the large amount of coordination required to prepare for the conversion while still accommodating normal maintenance activity.
U.S. Pat. No. 5,797,117 to Gregovich discloses a method wherein most of the unused portion of the month field in the date field (i.e., values of 13 through 99 for MM in YYMMDD) is used to identify the years 2000 through 2006. Starting on Jan. 1, 2000, the value for the month field increases by one for each successive month throughout the seven year period. The month field is not cleared every twelve months as in conventional schemes. Thus, the date field for Jan. 1, 2000 is 991301. The date field for Feb. 1, 2000 is 991401. The date field for Dec. 31, 2006, the final day in this seven-year solution, is 999631.
However, Gregovich at column 6, lines 1-2, teaches away from using the day field in the date field to solve the Y2K problem.
U.S. Pat. No. 5,600,836 to Alter discloses a method wherein time change interfaces convert 21st century date data to 20th century date data by subtraction. According to column 2, lines 8-11, the dates are in no more than two centuries.
U.S. Pat. No. 5,630,118 to Shaughnessy discloses a method wherein a subroutine, stored externally from the existing application programs in need of modification, converts existing six digit date fields to larger date fields including century data.
U.S. Pat. No. 5,644,762 to Soeder discloses a method which uses presently unused values within the existing six bytes of date fields in conventional systems to store data regarding the year. The years 00 to 99 only occupy a fraction of the two byte space allocated to year data. That is, two eight-bit bytes can represent any value from 0 through 65,535, but only two small subsets of this range are used to represent the values 00 to 99 under the ASCII and EBCDIC character sets. The values 0-12,335, 14,650-61,679 and 63,994-65,535 are free. Soeder proposes to solve the Y2K problem by integrating the existing year data with enhanced year data. In reading out a date, first the integer value of the two bytes of data written into the year value is determined. If this integer value is below 12,336, the integer value itself is taken to be the number of the year. If the integer value is in one of the subsets of the range reserved for existing character sets, the year is determined according to the appropriate character set.
U.S. Pat. No. 5,668,989 to Mao discloses a method comprising changing the data input/output mechanism, the storage and processing of 2 digit numbers, such that the higher digit of a 2 digit number is treated as a hexadecimal, and thus 160 (instead of 100) years can be represented with a 2 digit year number.
U.S. Pat. No. 5,740,442 to Cox et al. discloses a standardized method for identifying Y2K problems in programs and data.
U.S. Pat. No. 5,758,346 to Baird discloses a method wherein a system includes a database which stores representations of year data in either a two-digit or four-digit format, and a processor coupled to the database converts the representation into the other of the two-digit or four-digit format if the represented year falls within a floating window of years.
U.S. Pat. No. 5,761,668 to Adamchick discloses a method comprising converting existing YYMMDD characters to CYYDDD characters, wherein C is the century (starting with 1 as the 20th century) and DDD is the Julian day (0-366) of the year.
U.S. Pat. No. 5,765,145 to Masiello discloses a method, wherein day of the week data is used along with the conventional YYMMDD data to indicate the correct century.
U.S. Pat. No. 5,794,048 to Brady purports to disclose a method for identifying year-related fields in a program.
Despite the previous purported solutions to the Y2K problem, there is still room for improvement in the art. It would be advantageous to have a solution which minimizes the coordination efforts necessary to implement the solution, and which minimizes the downtime experienced by the application system.
All references cited herein are incorporated herein by reference in their entireties.